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(57) Abstract: An online machine data collection 
and archiving process (15) generates a machine data 
profile (18) of a customer computer (5) accessing a 
transaction form of a merchant web site (3) and links the 
machine data profile (18) and a transaction record (6) 
with customer identifying information using a unique 
transaction identification string. The process preferably 
captures parameters typically communicated as part of 
web accesses, such as an IP address, an HTTP header, 
and cookie information. The process additionally causes 
the customer computer (5) to process self-identification 
routines by processing coding within the merchant 
transaction form, the self-identification routines 
yielding further profile parameters. The process further 
includes a routine for bypassing an intervening proxy 
to the merchant web site (3) to reveal the true IP address 
of the customer computer (5). 
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1 ONLINE MACHINE DATA COLLECTION AND ARCHIVING PROCESS 

2 

3 Cross-Reference to Provisional Application 

4 This application claims benefits from provisional application, Serial No. 

5 60/209,936 filed June 7, 2000 and entitled METHOD FOR COLLECTING MACHINE 

6 DATA FROM CUSTOMERS ON A COMPUTER NETWORK. 
7 

8 Background of the Invention 

9 The present invention relates to identity detection techniques and, more 

1 0 particularly, to a process for collecting and utilizing machine-identifying data of computers 

1 1 and other online appliances used in online interactions and transactions and associating the 

1 2 collected machine data with such online interactions. 

1 3 The internet, or global computer network, represents a new medium for marketing 

1 4 similar to the way mail ordering and telephone ordering did in the past A downside of 

1 5 internet marketing is that it also presents new opportunities for unscrupulous persons to 

1 6 take advantage of the mechanisms of internet transactions by fraudulent and deceptive 

17 practices. Merchants and financial institutions bear the initial costs of fraud. However, 

1 8 consumers ultimately pay the costs in the form of prices and credit rates which must take 

1 9 into account losses from fraud. Internet purchases typically involve the use of web page 
2 0 forms which are filled in by the customer with identity, address, purchase, shipping, and 
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1 The IP address of a page requesting computer can give an indication of the specific 

2 country where the computer is located. Further, identification of a page-requesting 

3 computer can also recognize a returning user using the same computer as during a 

4 previous access. For example, placing an HTTP (hypertext transfer protocol) "cookie" on 

5 a page-requesting computer can make it possible to identify the computer on a later 

6 access. 

7 Because direct interaction with a customer's computer is essential in detecting 

8 fraud, it has been assumed that any viable fraud detection software must be integrated with 

9 a merchant's software. As a result, most existing fraud detection solutions require 

1 0 merchants to either abandon or extensively modify their existing web-based transaction 

1 1 processing software. An additional problem with focusing fraud detection at single 

12 merchants is that perpetrators of fraud often hit many merchants in an attempt to avoid or 

1 3 delay detection. Thus, an ideal system for fraud detection in online marketing would only 

1 4 minimally affect the merchant's existing software and would route fraud detection efforts 

1 5 through a central, third-party entity serving a large multitude of merchants. 
16 

17 Summary of the Invention 

1 8 The present invention provides a process for collecting data associated with a 

1 9 customer's computer during access of a merchant, financial, other host web site, and 

2 0 associating a transaction identification number with the data and with a transaction form of 

21 the merchant. Generally, the present invention captures machine identifying data from a 
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1 medium, and/or the true machine characteristics of the accessing appliance is/are essential 

2 or desirable to the interaction. 

3 The host entity which operates the host system accessed is intended to encompass 

4 a commercial, financial, educational, governmental, associational, or other type of entity. 

5 The term "merchant" will be used herein to refer to such a host entity without intent to 

6 limit the present invention to commercial transactions. The medium of access is intended 

7 to be interpreted as including a global computer network such as the internet or world 

8 wide web, as well as other types of networks which may be less than global but which are 

9 publicly and/or anonymously accessible. The term "internet" will be used herein to refer 

10 to the medium through which accesses to the host entity are made. The terms "customer 

1 1 computer" or "machine" are used herein to refer to a device for effecting remote access to 

12 a host system over a digital medium and are meant to encompass not only conventional 

1 3 types of personal computers, but also additional types of "digital appliances" with online 

1 4 access capabilities, such as: cell phones, personal digital assistant devices, electronic game 

1 5 systems, television sets with online access capabilities, web appliances for vehicles, and 

1 6 any other type of device with online access capabilities whether connected to a wired 

1 7 communications network directly or by a radiant technology. 

1 8 The machine data collection process of the present invention contemplates a two 

1 9 party process embodiment in which a "merchant" processes and/or stores machine data 
2 0 profiles of customer computers in-house, as well as a three party process embodiment in 
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1 computers accessing the second party or merchant web site is communicated to and stored 

2 within a third party system, referred to herein §s a machine data archive service. In the 

3 three party process, the transaction ID could be generated by the merchant system, but is 

4 preferably generated by the archive service. The use of the term "archive" is not meant to 

5 indicate that the customer machine data profiles are stored permanently within the third 

6 party system. Permanent storage of such profiles may not be practical, as far as yielding 

7 beneficial results to the purposes for which the profiles are collected. Thus, the term 

8 "archive" is meant to indicate a central storage facility, such as a database, with a selected 

9 retention period, with purging of most profiles after a certain length of time. 

10 In the three party process a routine or line of code is added into the hypertext 

1 1 markup language (HTML) code which defines the merchant's web page, particularly an 

1 2 order or transaction form page. The added routine issues a request for a machine data 

1 3 collection (MDC) script to the third-party web rite when the form page code is processed 

14 by the customer's browser. When the script request is received by the machine data 

1 5 archiving service (MDAS), the archive service generates a unique transaction 

1 6 identification (J A/ID) and checks for its own cookie. If no MDAS cookie is present, the 

1 7 archive service sends a cookie to the requesting computer along with a machine data 

1 8 collection (MDC) script having the transaction ID embedded therein. The MDC script is 

1 9 executed by the customer's browser, causing collection of certain data from the 

2 0 customer's computer which is sent back to the archive service along with the transaction 

21 ID and stored in a machine data profile in the machine data archive. The transaction ID is 
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1 on the string of codes representing the characters. The particular conversion process or 

2 hashing function used may be one of many types of conventional conversion algorithms or 

3 hashing fiinctions, which are typically used for data integrity tests. The resulting string 

4 from the MDC conversion process is a so-called fingerprint, which is returned to the 

5 archive service along with the transaction ID for storage in the machine profile. A time 

6 value, queried from the customer computer time-of-day clock, is returned with the 

7 fingerprint string and stored in conjunction therewith. 

8 An HTTP proxy is one of several types of proxies through which a browser may 

9 be setup to operate. Setting up an HTTP proxy causes HTTP requests to be relayed by a 

1 0 primary gateway, through which the computer actually interfaces to the internet, to a 

1 1 remote secondary gateway, or proxy, with an IP address different from the primary 

12 gateway IP address. Such redirection hides the true IP address of a computer. The proxy 

1 3 piercing operation of the MDC script queries the customer computer for any LAN (local 

1 4 area network) address which may be assigned to the computer and reads the system time 

15 of day clock. Then attempts are made to send the IAN address, if any, the time value, 

1 6 and the transaction ID to the archive service using a protocol winch will not be redirected 

1 7 through the HTTP proxy, for example a lower level protocol such as TCP/IP or UDP 

1 8 protocols. If the attempt is successful, the message containing the time value, the 

1 9 transaction ID, and LAN address arrive at the archive service web site with the true return 

20 IP address of the customer computer, whether an HTTP proxy intervenes or not. The 

2 1 LAN address and IP address so derived are stored in the machine profile. It should be 
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1 Brief Description of the Drawings 

2 Fig. 1 is a simplified block diagram illustrating a plurality of customer and 

3 merchant computers interfaced to the internet along with a machine data archiving service 

4 computer for practicing the machine data collection process of the present invention. 

5 Fig. 2 is a simplified block diagram illustrating connection of a customer computer 

6 to the internet, with optional components shown in phantom lines. 

7 Fig. 3 is a flow diagram illustrating principal steps of the machine data collection 

8 and archiving process according to the present invention. 

9 Fig. 4 is a flow diagram illustrating more detailed steps of the machine data 

1 0 collection and archiving process according to the present invention 

1 1 Fig. 5 is a flow diagram illustrating a still further detailed steps in the machine data 

1 2 collection and archiving process of the present invention. 

1 3 Various objects and advantages of this invention will become apparent from the 

1 4 following description taken in relation to the accompanying drawings wherein are set 

1 5 forth, by way of illustration and example, certain embodiments of this invention. 

1 6 The drawings constitute a part of this specification, include exemplary 

1 7 embodiments of the present invention, and illustrate various objects and features thereof 
18 

19 
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1 use of form type web pages with which the customers 5 interact by filling in various data 

2 fields, for example, name, address, shipping address, telephone number, credit card type 

3 and number and expiration date, and description and quantities of products to be ordered. 

4 The merchant transaction forms are usually written in hypertext markup language 

5 (HTML) and may include requests for code written in other languages, such as Java and 

6 the like. When a customer 5 accesses a merchant's transaction form, a transaction form 

7 file is communicated to the customer's computer with various data fields displayed as fill- 

8 in boxes or the like. The customer fills in the appropriate fields and selects a submit 

9 "button" which activates a routine to transfer the collected information back to the 

1 0 merchant web site 3 for processing. The returned "form" is a data record 6 which is 

1 1 stored in a merchant transaction database 7 for retrieval and processing in due course to 

12 cause the ordered items to be gathered, packaged and prepared for shipment, along with 

1 3 financial processing to debit the customer's credit account. The financial processing may 

1 4 include a validity check of the credit account and an authorization check for the amount of 

1 5 purchase with the credit card issuer. Additionally, inventory management processes are 

1 6 executed based on the items withdrawn from stock for shipment. 

17 In a three party embodiment of the present invention, the process 1 makes use of 

18 an entity referred to herein as a machine data archiving service, MDAS or archive service, 

1 9 which operates an archive service computer system 15, including an archive service web 
2 0 site 16. The archive service system 15 maintains a machine data archive service database 
21 or archive 17 in which the machine data collection profiles 18 from customer computers 5 

13 
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1 The customer computer 20 may have a fixed IP address, depending on the manner 

2 in which it is interfaced, to the internet. More commonly, the customer computer 20 will 

3 have a temporary or dynamically assigned BP address which is determined by the primary 

4 router 22. The primary router 22 has an IP address, as do a router of a LAN 24 or an 

5 HTTP proxy 26 if either is present in the customer's computer system 5. 

6 Fig. 3 illustrates the principal actions or steps of a general or basic process 34 of 

7 the process 1 for collecting machine identifying data from customer computers 5. At step 

8 35, at least one machine identifying profile parameter is captured upon access of a 

9 customer computer 5 or other online access device with a host or merchant web site 3. A 

1 0 unique transaction identifier or TA/ID is generated at 36 and associated at 37 with the 

1 1 captured profile parameter. The transaction ID is also associated at step 38 with a 
, 12 transaction record generated as a result of the interaction or transaction conducted 

1 3 between the customer computer 5 and a merchant web site 3 . Although not specifically 

1 4 shown in Fig, 3, the process 34 may capture machine profile data that is passed from the 

1 5 customer computer 5 to the merchant computer 3 as an inherent step of the customer 

1 6 computer 5 accessing the merchant computer 3 . Alternatively, the process 34 may pass 

1 7 routines to the customer computer 5 to cause it to "self-identify" itself by querying certain 

1 8 configuration parameters and passing such information to a machine profile stored either 

1 9 within the merchant's system 2 or in a third party archive 17. The process 34, thus, 

2 0 encompasses a two-party embodiment or a three party embodiment of the machine data 

2 1 collection and archiving process 1 of the present invention. 

15 
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1 merchant's transaction database 7, Thereafter, qualified parties may access the MDAS 

2 archive 17 for information related to a transaction ID. 

3 The MDAS archive 17 need not contain any information which specifically 

4 identifies a particular customer, only the machine parameter profiles 18 with associated 

5 transaction ID strings. The MDAS archive records 18 can be analyzed in conjunction with 

6 the merchant transaction records for patterns of fraud or for other purposes . The great 

7 majority of MDAS archive records can be purged from the archive 17 after a selected 

8 period of time. Any records which are associated with any transaction irregularities or 

9 suspicions of actual fraud may be retained longer. 

1 0 Fig. 5 illustrates the principal steps of a preferred embodiment 60 of the machine 

1 1 data collection and archiving process 1 of the present inventioa The process 60 begins 

12 with the addition at 62 of a machine data collection (MDC) script to the transaction (TA) 

1 3 form page code of a merchant web site 3. The transaction form page code is processed at 

14 64 by a customer browser 28 when the Merchant web page is accessed to thereby request 

15 the MDC script at 66 from the Machine data archive service (MDAS) web site 16. When 

16 the browser 28 accesses the MDAS web site 16, requesting the MDC script, the MDAS 

1 7 web site checks for the presence of an MDAS cookie at step 68. If no MDAS cookie is 

1 8 detected, an MDAS cookie is generated at 70 and a unique transaction identification 

1 9 (TA/ID) string is generated at 72. The MDC script, transaction ID, and cookie, if not 
2 0 previously set, are returned at 74 to the customer browser 28, the transaction ID being 
2 1 embedded within the MDC script. 

17 



WO 01/97134 



PCT/US01/18076 



2 
3 
4 



Wto« h eMDC S cdp ti5 ^ bytte(!rowser2g . tisexecutedat7( . ^ 

MDC scrip, writes U* Morion m ht0 fc mmahn [gm M ^ ^ ^ ^ ^ 

^orbywriring^^^e^^^^^^^^^ 
vaHteto^tren^n^ Mi^*^*,,,,^,^ 

piercing operation at step 82. 

*g M ^ ttera ^e^en»ri^ 

^.^^w** toa ^^ rfun ^ Hashing fiaKrions are 

thedauo^ea^^^. ^ H^frncrionaareconnnon* 

of.^eofhashi.g^ ^parric^aasi^^^^^ 
maxtokes ,te uniqueness of tie resulting fingetprint 

At^ttecu^contpnterdo^ ^ 
«ep88, fltefinge^ritn, the tren^ n>, andtne,in K v^e.re«»nnn«^ tonie 



18 



WO 01/97134 



PCT/US01/18076 



1 MDAS web site 16 along with an HTTP header with cookie and "apparent" IP address, all 

2 of which are stored as $ machine data profile IB within the MDAS archive 17. 

3 At step 90, the MDC script adds a proxy piercer request to the transaction form 

4 which, when executed by the browser 28 at step 92, sends a request for a proxy piercer 

5 applet or code to the MDAS web site 16. When the proxy piercer applet/code is executed 

6 by the browser 28 at 94, a time value from the clock 32 is again queried at 96 and any 

7 existing local area network (LAN) address is queried at 98. At step 100, the proxy piercer 

8 applet/code sends the time value, the LAN address Of any), and the transaction ID to the 

9 MDAS web site 16 by a protocol which bypasses any existing HTTP proxy 26. The 

1 0 protocol used is one which is at a lower level than HTTP, such as UDP (user datagram 

11 protocol) or, preferably, TCP/IP (transmission control protocol/internet protocol). 

12 Bypassing the HTTP proxy 26 causes the data sent in step 100 to arrive at the 

1 3 MDAS web site 16 with the IP address of the primary gateway 22, which may be different 

1 4 from any apparent IP address previously recorded if an HTTP proxy 26 intervenes. If the 

1 5 proxy piercer procedure 82 is successful, the primary gateway IP address is stored at step 

16 102 within the machine data profile 18 identified by the transaction ID. It should be noted 

17 that some types of proxies, such as some types of firewalls, may block all non-HTTP 

1 8 protocol packets, so that the proxy piercer procedure 82 might not be successful in all 

19 cases. 
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1 and the machine parameter set. An exemplary transaction ID is a string of 24 letters and 

2 digits. The first eight digits form a time- stamp which is a hexadecimal representation of 

3 the seconds elapsed since midnight January 1, 1970 UTC (coordinated universal time). 

4 In the preferred embodiment of the process 1, the MDC script is written in an 

5 ECMAScript compliant language, such as JavaScript, JScript, or VBScript. A JavaScript 

6 version of the MDC script is as follows (linebreaks and indentations added for clarity): 
7 

8 document. write("<input name=transactionid type^hidden value= s Z2K>; 
9 

10 d=new DateO; 
11 

12 t=3600*d.getHoura()^0M.gelMmutes0+d.getSeconds0; 
13 

14 document. write("<3mgheight=l width=l src=https://www.example- 

15 url.net/t/?i=ZZZ&t= H +t+ ,, > M ); 
16 

17 document. write("<applet height=l width^l 

18 codebase=https://www.example-url.net/ 

19 code=a/?ZZZ> 

2 0 <param name=i value=ZZZx/applet>"); 
21 
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1 c) it sends this data back to the archive service 16 via TCP/IP, by requesting 

2 thefoUowirigURL: 

3 http://ww.exampl^ 

4 The archive service 16 receives the message which includes the parameters TTT, 

5 AAA and 777 The message also includes the IP address of the sender. This address is 

6 the customer's actual IP address, which in some cases is different from the HTTP proxy IP 

7 address. The archive service 16 records this information in the MDAS archive 17 and 

8 associates it with the transaction ID ZZZ. 

9 The machine data collection and archiving process 1 of the present invention has 

1 0 been described with a particular application in fraud detection. However, it is foreseen 

1 1 that the techniques of the present invention have a wider application, as for marketing or 

12 computer support purposes, or other functions. While the process 1 has been described 

1 3 with reference to the internet 4 or world wide web, it is also conceivable that the process 1 

1 4 could be employed on computer networks of less than global expanse, such as a large 

1 5 intranet, a national or regional network, or the like. 

1 6 Therefore, it is to be understood that while certain forms of the present invention 

1 7 have been illustrated and described herein, the present invention is not intended to be 

1 8 limited to the specific forms, arrangement of parts, sequence of steps, or particular 

1 9 applications described and shown. 
20 
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4. A process as set forth in Claim 1 and including the steps of: 

(a) communicating a self-identification routine to said access device upon said 
access device accessing said host computer system; 

(b) said access device executing said self-identification routine; 

(c) said self-identification routine, querying a configuration setting of said 
access device to derive said profile parameter; and 

(d) said self-identification routine communicating said profile parameter to a 
remote location for association with said interaction identification string. 

5. A process as set forth in Claim 1 and including the steps of: 

(a) said host system operating a host web site including an interaction page 
generated by interaction page code processed by said access device upon 
accessing said host web site; and 

(b) coding, within said interaction page code, a self-identification routine 
which causes said access device to communicate said profile parameter 
when said access device processes said interaction page code. 

6. A process as set forth in Claim 3 and including the Step of: 

(a) coding said self-identification routine in such a manner that said profile 
parameter and said interaction identification string are communicated to a 
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identification string are stored, 
the steps of 
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9. A process as set forth in Claim 7 wherein said capturing step includes the step of: 
(a) capturing a configuration setting of said customer computer. 

10. A process as set forth in Claim 7 and including the step of: 

(a) communicating said profile parameter and said transaction identification 
string to a third party web site for storage. 

11. A process as set forth in Claim 7 and including the step of: 

(a) causing said customer computer to communicate said profile parameter and 
said transaction identification string to a third party web site for storage. 

12. A process as set forth in Claim 7 and including the steps of: 

(a) communicating a self-identification routine to said customer computer 
upon said customer computer accessing said merchant web site; 

(b) said customer computer executing said self-identification routine; 

(c) said self-identification routine querying a configuration setting of said 
customer computer to derive said profile parameter; and 

(d) said self-identification routine communicating said profile parameter to a 
remote location for association with said interaction identification string. 
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operating on said customer computer and a merchant who operates said web site, 
said method comprising the steps of: 

(a) coding a script request within a transaction form of said merchant web site; 

(b) processing said script request by said customer browser upon accessing 
said merchant web site to thereby communicate to an archiver web site of a 
machine data archiving service an electronic request for a machine data 
collection script; 

(c) said archiver web site returning said script to said customer browser along 
with a unique transaction identification string; 

(d) said customer browser processing said script to thereby cause said script to 
query said customer computer for a profile parameter of said customer 
computer, 

(e) said script causing said customer browser to communicate said profile 
parameter and said transaction identification string to said archiver web 
site; 

(f) said archiver web site storing said profile parameter and said transaction 
identification string in a machine data profile; 

(g) said script causing said customer browser td write said transaction 
identification string into said transaction form; and 

(h) upon said customer adding customer identification information to said 
transaction form and electronically submitting said transaction form to said 
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(c) said script processing said attribute string to form said profile parameter of 
said customer computer/ 

20. A process as set forth in Claim 19 wherein said script processing step includes the 
step of: 

(a) said script performing a hashing function on said attribute string to form 
said profile parameter. 

21. A process as set forth in Claim 16 wherein said customer computer potentially 
accesses said merchant web site by way of a proxy, and including the step of: 
(a) said script communicating said profile parameter and said transaction 

identification string to said archiver service web site using a protocol which 
bypasses said proxy. 

22. A process as set forth in Claim 16 and including the step of: 

(a) said script communicating said profile parameter to said archiver service 
web site using a protocol other than HTTP. 

23. A process as set forth in Claim 16 wherein said customer computer includes a 
digital clock, and including the steps of: 
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(•) said script causing said customer browser to quay said clock for a time 
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(3) perform a hashing function on said attribute string to form said 
profile parameter; and . 

(4) query an internal digital clock of said customer computer for a 
current time value; 

(e) said script causing said customer browser to communicate said profile 
parameter, said time value, and said transaction identification string to said 
archiver web site along with a conventional HTTP header; 

(f) said archiver web site storing said profile parameter, said time value, and 
said transaction identification string in a machine data profile; 

(g) said script causing said customer browser to write said transaction 
identification string into said transaction form; and 

(h) upon said customer adding customer identification information to said 
transaction form and electronically submitting said transaction form to said 
merchant web site to thereby comprise a transaction record, said 
transaction identification string associating said transaction record with said 
machine data profile. 

25. A process as set forth in Claim 24 wherein said customer computer potentially 
accesses said merchant web site by way of a proxy, and including the steps of: 
(a) said script querying said customer computer for a second profile parameter; 
and 
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